2-10 情景七：多仓库管理&跨仓库clone三种方案
场景描述
项目依赖多个独立的仓库（如公共组件库、工具库等），需要在主项目中引用和管理这些外部代码。
方案一：Git Submodule
将外部仓库作为子目录嵌入主项目，保持独立的版本控制。
# 添加子模块
git submodule add https://github.com/team/shared-components.git libs/shared
# 克隆含子模块的项目
git clone --recurse-submodules https://github.com/team/main-project.git
# 更新子模块到最新
git submodule update --remote
bash
优点：每个仓库独立管理。缺点：操作繁琐，团队成员容易忘记初始化子模块。
方案二：Git Subtree
将外部仓库的代码合并到主项目的子目录中，不需要额外的 Git 命令。
# 添加远程仓库
git remote add shared https://github.com/team/shared-components.git
# 拉取并合并到子目录
git subtree add --prefix=libs/shared shared main --squash
# 后续更新
git subtree pull --prefix=libs/shared shared main --squash
bash
优点：不需要额外的 Git 操作，克隆时自动包含。缺点：命令较长，历史记录可能混乱。
Subtree 命令行简化
subtree 在操作时，命令行较长，可以使用 remote 配置简化：
# 以下为标准 subtree add 命令行示例
git subtree add --prefix=centos-config --squash git@github.com:toimc/centos-config.git master
# 可以简化为
# 1. 先为远程子仓库配置一个别名，便于后续的 pull 与 push 操作
git remote add centos git@github.com:toimc/centos-config.git
# 2. --prefix= 简写为 -P，--squash 表示不拉取子仓库的历史提交记录
git subtree add -P centos-config --squash centos master
# 后续更新子仓库可以使用
# 若发生 fatal: refusing to merge unrelated histories 报错，加上 --squash 参数即可
git subtree pull -P centos-config centos master
bash
方案三：Monorepo
将所有相关项目放在同一个仓库中，使用目录划分。
monorepo/
├── packages/
│ ├── app/
│ ├── shared-components/
│ └── utils/
├── package.json
└── pnpm-workspace.yaml
text
优点：统一管理，原子提交。缺点：仓库可能变得很大。
Subtree 与 Submodule 深度对比
| 维度 | Subtree | Submodule | 优劣对比 |
|---|---|---|---|
| 空间占用 | 初始化 add 时，会将子仓库 copy 到父仓库中，并产生至少一次 merge 记录，占用大量父仓库空间 | 初始化 add 时，在父仓库新建 .gitmodules 文件，仅保存子仓库的 commit hash 引用，不占用父仓库空间 | submodule 更优 |
| clone | subtree add 至父仓库之后，后续的 clone 操作与单一仓库操作相同 | 后续 clone 时 submodule 还需要 init/update 操作，且子仓库有自己的分支 | subtree 更优 |
| update | 子仓库更新后，父仓库需要 subtree pull 操作，命令行略长，需指定 --prefix 参数。由于无法感知子仓库的存在，可能产生 merge 冲突 | 子仓库更新后，父仓库需要 submodule update 操作。父仓库只需变动子仓库 hash 引用，不会出现冲突 | submodule 更优 |
| commit | 父仓库直接提交父子仓库目录里的变动。若修改了子仓库的文件，则需要执行 subtree push | 父子仓库的变动需要单独分别提交，且注意先提交子仓库再提交父仓库 | subtree 更优 |
总结：
git subtree：将已有的项目作为子模块集成到其他项目中，或者将某个子目录独立出来作为新项目管理。适合管理已有的项目之间的依赖关系。父仓库会跟踪子仓库中的文件变化，子仓库的变化会直接影响父仓库。git submodule：将一个仓库作为子模块嵌入到另一个仓库中。子模块的代码独立管理，可以在父仓库中指定子模块所需的版本，并且可以在子模块中进行开发和提交。适合管理独立的子仓库。父仓库不会跟踪子仓库中的文件变化，子仓库的变化需要单独处理。
方案总览对比
| 方案 | 独立版本控制 | 操作复杂度 | CI/CD 隔离 | 适用场景 |
|---|---|---|---|---|
| Submodule | 是 | 高 | 天然隔离 | 松耦合的独立库 |
| Subtree | 否 | 中 | 需配置 | 频繁引用的外部库 |
| Monorepo | 否 | 低 | 需配置 | 紧密相关的项目 |
参考资源
↑